HOLD: Fix registration closed error caused by timezone mismatch in event form#1020
HOLD: Fix registration closed error caused by timezone mismatch in event form#1020
Conversation
|
@copilot try again |
Fixed in commit 5af20b4. The issue was a timezone mismatch in the event form. The Problem: The Fix: Changed in
Example: A registration close date stored as |
|
@copilot should this be referencing the time_zone on user? |
You're right! Changed in commit 8f5e323 to explicitly use |
8f5e323 to
a160e6e
Compare
Co-authored-by: maebeale <7607813+maebeale@users.noreply.github.com>
Co-authored-by: maebeale <7607813+maebeale@users.noreply.github.com>
- Remove redundant .in_time_zone() calls from datetime-local fields; these are already handled by around_action :set_time_zone_from_user - Add comment documenting the timezone dependency - Fix spec DST bug: use January dates (PST/UTC-8) instead of March dates which fall in PDT (UTC-7) after DST starts March 8 - Use Time.use_zone in spec to properly simulate the around_action - Fix rubocop: single quotes to double quotes
a160e6e to
1c610e8
Compare
What is the goal of this PR and why is this important?
This PR fixes a bug where events were incorrectly showing "Registration closed" even when the
registration_close_datewas in the future. The issue was caused by a timezone mismatch in the event form that caused registration dates to shift into the past after users saved event edits.How did you approach the change?
Root Cause: The event form displayed UTC times from the database without converting to the user's local timezone. When users saved the form (even without changes), Rails interpreted the datetime-local values as being in the user's timezone, causing the stored times to shift. For example, a Pacific timezone user would see a date shift by 8 hours into the future, making it appear that registration had already closed.
Solution: Modified
app/views/events/_form.html.erbto explicitly usecurrent_user.time_zonefor timezone conversion on all three datetime fields (start_date,end_date,registration_close_date) before displaying them. This ensures:registerable?logic works correctlyChanged from using
Time.zone(which relies onaround_actionin ApplicationController) to directly usingcurrent_user&.time_zone || "UTC"for better clarity and explicitness.Example: A registration date stored as
2026-03-15 20:00 UTCnow correctly displays as2026-03-15T12:00for Pacific timezone users (12 PM Pacific) instead of2026-03-15T20:00, preventing the date shift that occurred on save.Anything else to add?
Testing:
spec/views/events/_form_timezone_spec.rbto verify timezone conversionThe fix directly references the user's
time_zoneattribute rather than depending on thearound_actionto setTime.zone, making the code more explicit and self-documenting.💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.